mycat系列-MySQL主从复制的几种方案
数据库读写分离对于大型系统或者访问量很高的互联网应用来说，是必不可少的一个重要功能。
从数据库的角度来说，对于大多数应用来说，从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即SQL查询的瓶颈，我们知道，正常情况下，Insert SQL就是几十个毫秒的时间内写入完成，而系统中的大多数Select SQL则要几秒到几分钟才能有结果，很多复杂的SQL，其消耗服务器CPU的能力超强，不亚于死循环的威力。在没有读写分离的系统上，很可能高峰时段的一些复杂SQL查询就导致数据库服务器CPU爆表，系统陷入瘫痪，严重情况下可能导致数据库崩溃。因此，从保护数据库的角度来说，我们应该尽量避免没有主从复制机制的单节点数据库。
对于MySQL来说，标准的读写分离是主从模式，一个写节点Master后面跟着多个读节点，读节点的数量取决于系统的压力，通常是1-3个读节点的配置，如下图所示：
MySQL支持更多的主从复制的拓扑关系，如下图所示，但通常我们不会采用双向主从同步以及环状的拓扑：
MySQL主从复制的原理如下：
第一步是在主库上记录二进制日志（稍后介绍如何设置）。在每次准备提交事务完成数 据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序 而非每条语句的执行顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引 擎可以提交事务了。 下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动一个 工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启 动一个特殊的二进制转储(binhg dump、线程（该线程没有对应的SQL命令），这个二 进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程 追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会 被唤醒，备库I/O线程会将接收到的事件记录到中继日志中。
备库的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现 备库数据的更新。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所 以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自 己的二进制日志中，它对于我们稍后提到的场景非常有用。这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说 I/o线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要 的一点是在主库上并发运行的査询在备库只能串行化执行，因为只有一个SQL线程来重 放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在。虽然有 一些针对该问题的解决方案，但大多数用户仍然受制于单线程。MySQL5.6以后，提供了基于GTID多开启多线程同步复制的方案，即每个库有一个单独的(sql thread)
进行同步复制，这将大大改善MySQL主从同步的数据延迟问题，配合Mycat分片，可以更好的将一个超级大表的数据同步的时延降低到最低。此外，用GTID避免了在传送 binlog 逻辑上依赖文件名和物理偏移量，能够更好的支持自动容灾切换，对运维人员来说应该是一件令人高兴的事情，因为传统的方式里，你需要找到binlog和POS点，然后change master to指向，而不是很有经验的运维，往往会将其找错，造成主从同步复制报错，在mysql5.6里，无须再知道binlog和POS点，需要知道master的IP、端口，账号密码即可，因为同步复制是自动的，mysql通过内部机制GTID自动找点同步。
即使是并发复制机制、仍然无法避免主从数据库的数据瞬间不同步的问题，因此又有了一种增强的方案，即galera for mysql、percona-cluster或者mariadb cluster等集群机制，他们是一种多主同步复制的模式，可以在任意节点上进行读写、自动控制成员，自动删除故障节点、自动加入节点、真正给予行级别的并发复制等强大能力!
下图是其原理图，通常是采用3个MySQL节点作为一个Cluster，即提供了3倍的数据库读的并发能力.galera for mysql集群这种方式，是牺牲了数据的写入速度，以换取最大程度的数据并发访问能力，类似Mycat里的全局表，并且保证了数据同时存在几个有效的副本，从而具有非常高的可靠性，因此在某种程度上，可以替代Oracle的一些关键场景，**目前开源中间件中，只有Mycat很完美的支持了galera for mysql集群模式。
MySQL主从复制的几个问题
MySQL主从复制并不完美，存在着几个由来已久的问题，首先一个问题是复制方式：
基于SQL语句的复制(statement-based replication, SBR)，
基于行的复制(row-based replication, RBR)，
混合模式复制(mixed-based replication, MBR)。
基于SQL语句的方式最古老的方式，也是目前默认的复制方式，后来的两种是MySQL 5以后才出现的复制方式。
RBR 的优点：
任何情况都可以被复制，这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技术一样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
RBR的缺点：
binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题
无法从 binlog 中看到都复制了写什么语句
SBR 的优点：
历史悠久，技术成熟
binlog文件较小
binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
binlog可以用于实时的还原，而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR 的缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
执行复杂语句如果出错的话，会消耗更多资源
选择哪种方式复制，会影响到复制的效率以及服务器的损耗，甚以及数据一致性性问题，目前其实没有很好的客观手手段去评估一个系统更适合哪种方式的复制，Mycat未来希望能通过智能调优模块给出更科学的建议。
第二个问题是关于主从同步的监控问题，Mysql有主从同步的状态信息，可以通过命令show slave status获取，除了获知当前是否主从同步正常工作，另外一个重要指标就是Seconds_Behind_Master，从字面理解，它表示当前MySQL主从数据的同步延迟，单位是秒，但这个指标从DBA的角度并不能简单的理解为延迟多少秒，感兴趣的同学可以自己去研究，但对于应用来说，简单的认为是主从同步的时间差就可以了，另外，当主从同步停止以后，重新启动同步，这个数值可能会是几万秒，取决于主从同步停止的时间长短，我们可以认为数据此时有很多天没有同步了，而这个数值越接近零，则说明主从同步延迟最小，我们可以采集这个指标并汇聚曲线图，来分析我们的数据库的同步延迟曲线，然后根据此曲线，给出一个合理的阀值，主从同步的时延小于阀值时，我们认为从库是同步的，此时可以安全的从从库读取数据。Mycat未来将支持这种优化，让应用更加可靠的读取到预期的从库数据。
Mycat支持的读写分离
当MySQL按照之前的主从复制方式配置好集群以后，可以开启Mycat的读写分离机制，以以下的配置为例，表明一个从节点hostS1与一个主节点hostM1组成了标准的一主一从的读写分离模式，参数balance决定了哪些MySQL服务器参与到读SQL的负载均衡中，具体参数参加前面章节。
注意如果配置了一个writeHost ，如果writeHost挂了，下面的所有readHost都无法使用，如果需要配置为主从的模式需要配置两个writeHost的模式。
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native"> <heartbeat>select user()</heartbeat> <!-- can have multi write hosts --> <writeHost host="hostM1" url="localhost:3306" user="root" password="123456"> <!-- can have multi read hosts --> <readHost host="hostS1" url="localhost2:3306" user="root" password="123456" /></writeHost> </dataHost>writeType=1仅仅对于galera for mysql集群这种多主多节点都能写入的集群起效，此时Mycat会随机选择一个writeHost并写入数据，对于非galera for mysql集群，请不要配置writeType=1，会导致数据库不一致的严重问题。Mycat目前支持自动方式、编程指定的两种读写分离方式：自动方式，即一个查询SQL是自动提交模式，对应于connection.setAutocommit(true) 或者 set autocommit=1编程指定方式，即一个查询SQL语句以/*balance*/注解来确定其是走读节点还是写节点。在1.3版本里，若事务内的的查询语句增加此注解，则强制其走读节点，而1.4版本里继续强化，可以在非事务内的查询语句前增加此注解，强制走写节点，这个增强是为了避免主从不同步的情况下要求查询到刚写入的数据而做的增强。另外 1.4开始支持MySQL主从复制状态绑定的读写分离机制，让读更加安全可靠，配置如下：MyCAT心跳检查语句配置为 show slave status ，dataHost 上定义两个新属性： switchType="2" 与 slaveThreshold="100"，此时意味着开启MySQL主从复制状态绑定的读写分离与切换机制，Mycat心跳机制通过检测 show slave status 中的 "Seconds_Behind_Master", "Slave_IO_Running", "Slave_SQL_Running" 三个字段来确定当前主从同步的状态以及Seconds_Behind_Master主从复制时延，当Seconds_Behind_Master>slaveThreshold时，读写分离筛选器会过滤掉此Slave机器，防止读到很久之前的旧数据，而当主节点宕机后，切换逻辑会检查Slave上的Seconds_Behind_Master是否为0，为0时则表示主从同步，可以安全切换，否则不会切换。switchType 目前有三种选择：- -1 表示不自动切换- 1 默认值，自动切换- 2 基于MySQL主从同步的状态决定是否切换下面为参考配置：<dataHost name="localhost1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="2" slaveThreshold="100"> <heartbeat>show slave status </heartbeat> <!-- can have multi write hosts --> <writeHost host="hostM1" url="localhost:3306" user="root" password="123456"> <!-- can have multi read hosts --> </writeHost> <writeHost host="hostS1" url="localhost:3316" user="root" password="123456" /></dataHost>conf/log4j.xml中配置日志输出级别为debug时，当选择节点的时候，会输出如下日志：16:37:21.660 DEBUG [Processor0-E3] (PhysicalDBPool.java:333) -select read source hostM1 for dataHost:localhost116:37:21.662 DEBUG [Processor0-E3] (PhysicalDBPool.java:333) -select read source hostM1 for dataHost:localhost1根据这个信息，可以确定某个SQL发往了哪个读（写）节点，据此可以分析判断是否发生了读写分离。用MySQL客户端连接到Mycat的9066管理端口，执行show @@datanode ，也能看出负载均衡的情况，其中execute字段表明该分片上执行过的SQL累计数：
至于应用中的哪些数据查询比较适合开启读写分离，总结下来大概有以下几种：
- 列表界面，通常是浏览查询功能，这类的数据访问频繁但实时性要求比较低，有几秒几十秒的延迟，通常感觉不出来，淘宝界面里，已售出的商品个数往往比商家后台看到的数据要延迟很大，也说明了它是一个快照数据- 某个数据的详细信息页面，通常也访问较为频繁，但事实性要求不高- 历史时刻的数据，比如昨天的数据，上个月的，这种数据即使有修改，也概率很低Mycat的读写分离，默认是按照该SQL是否有事务包裹，由于一些高层框架如Hibernate、Spring等往往会自动追加事务控制语句，将查询语句变成事务内的语句，当你开启Mycat Debug日志级别后，就可能很清楚的看到这一点，日志中会出现如下的序列，此时不会走读写分离，因此建议程序设计的时候，手工控制事务，让这些查询语句自动提交，这个做法也有利于加快MySQL的执行过程。